Skip to content

refactor(gotrue): Remove unused _currentUser field and update currentUser getter logic. #1168

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

juampiq6
Copy link

@juampiq6 juampiq6 commented May 7, 2025

What kind of change does this PR introduce?

Refactor

What is the current behavior?

_currentUser variable is just being stored as a copy of _currentSession.user

What is the new behavior?

The currentUser getter is handling the indirection correctly, no need to duplicate values and assign both each time they change.

Additional context

I have simplified a comment (it was a double negation).
I have added some bang operators in cases where null-aware operator where not needed

…User getter logic. Simplified comments and fixed some nullcheck operators
@@ -997,7 +992,7 @@ class GoTrueClient {
}
} else {
final shouldEmitEvent = _currentSession == null ||
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if current session is null, then the second bang operator in the expression will never reach

@@ -748,8 +745,7 @@ class GoTrueClient {
options: options);
final userResponse = UserResponse.fromJson(response);

_currentUser = userResponse.user;
_currentSession = currentSession?.copyWith(user: userResponse.user);
_currentSession = currentSession!.copyWith(user: userResponse.user);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if access token is null, then the code will never reach the bang operator, hence it should be safe to use it here

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't say so because there is an async request in between, so the current session can be removed during the request.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe im missing something, but that request cant modify the currentSession variable.
If im not wrong, that call would fail if the session or accessToken is not valid and throw an Exception, but never reach the bang operator.
Anyway, the main point of this PR is too delete a variable that is never actually used, we can leave the null-aware operator

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the request itself doesn't change the currentSession, but while the request is going a signout or something else could happen that sets the currentSession to null

@coveralls
Copy link

Pull Request Test Coverage Report for Build 14892732288

Details

  • 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 75.328%

Totals Coverage Status
Change from base Build 14868379526: 0.0%
Covered Lines: 2867
Relevant Lines: 3806

💛 - Coveralls

Copy link
Collaborator

@Vinzent03 Vinzent03 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way the library currently works, those removal are okay.
But the comment about a non-null User, but null Session on currentUser will never happen, because it's derived from _currentSession. So we could either remove that comment or don't do the changes of this pr and instead set the _currentUser only in signUp if a User exists, but no Session.

@@ -748,8 +745,7 @@ class GoTrueClient {
options: options);
final userResponse = UserResponse.fromJson(response);

_currentUser = userResponse.user;
_currentSession = currentSession?.copyWith(user: userResponse.user);
_currentSession = currentSession!.copyWith(user: userResponse.user);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't say so because there is an async request in between, so the current session can be removed during the request.

@juampiq6
Copy link
Author

I totally agree, the comment is wrong, the one I modified aswell. I would just leave:
/// Returns the current logged in user, asociated to [currentSession] if any;
About setting the _currentUser:
For that case where the user is not yet confirmed after SignUp, the AuthResponse would handle the User data needed.
The API of this library, in my opinion, should only expose a session, to not overcomplicate the understanding of this edge case.

@Vinzent03
Copy link
Collaborator

I agree, sounds reasonable!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants